A business information system can improve an organization's ability to monitor and manage data in a complex business environment. A business information system, such as the SAP Business Intelligence (“BI”) systems offered by SAP AG of Walldorf Germany, provides components and tools that allow users to retrieve, view and manipulate data from a number of different sources. Some items of data may be from internal sources (e.g., such as a company's internal database), while others may be from external or third party sources. As used herein, a company's “internal data” is data that is stored and maintained as part of the company's overall business intelligence solution. Some of the data, for example, may be associated with a “data warehouse” (generally referred to herein as a “business warehouse” or “BW”). The BW may be a combination of business information stored in a variety of ways, including in relational database, in memory databases, in data storage areas remote from the enterprise application systems and in virtual data sources (such as ad hoc data generated from business coding in the BW). As used herein, “external data” is data that is not processed or maintained by the analytical engine of the business information system.
A BW may include preconfigured data formats and conventions. As a result, it is relatively straightforward to query, view and manipulate “internal data” (or data from the BW). It can be more difficult, however, for a business information enterprise system to process requests, queries, or other interactions with external data or data from external data sources or other applications. For example, external data is typically formatted or configured differently from the internal data. One example of a type of transaction which is made more difficult by the need to access both internal and external data is the execution of a query to retrieve specified data. Business information enterprise systems typically provide some capability for users of the system to submit a query to retrieve and view data.
A “query view” is a definition of desired data, including a definition of what data to look for and how to arrange and format the data. The query view represents all of the settings an end user client application requires to provide the data to the end user. For example, a query view typically includes restrictions (or filters) that are applied to the data to be accessed. Specific illustrative examples are: product lines, company names, customer groups, fiscal year, distribution regions, product costs, product quantities, revenues, dates, etc. Data filters may be applied to further limit the result data. For example, result data can be filtered to identify illustrative features such as: the customers having revenue greater than 1 million dollars, the top 10 customers according to revenue, the customers having actual derivation to plan of greater 5%, etc. Query views may further include visualization settings to more efficiently display and format retrieved data. For example, visualization settings may include traffic light reporting or calculations based on the retrieved data (like ranking calculations) or the like. By providing such settings, the retrieval of data becomes more efficient and focused to a user's particular needs.
In existing systems, a query is generally executed by a query application (the “called application”) which is called by another application (the “calling application”) that will analyze the retrieved query data and add client applications on top of the retrieved query data. The query view is generally defined in a format native to the calling application rather than to the called application. As such, the calling application must include a translator to convert the query view into a format native to the called application. However, such an approach can become cumbersome, particularly when there are several different applications in a business information system that include query views, since each application has to have its own translator. In this case, a developer must know how to translate query views from each application's format to the format of the called application and then create all the translators. This is costly and time-consuming.
Some systems use Microsoft® XMLA for data retrieval. However XMLA/MDX only describes the data retrieval part in a structured query language (SQL)-like manner. Therefore calling applications typically have their own model on top of it and generate XMLA/MDX for data access based on their model. The generation of XMLA/MDX is quite complicated, because XMLA/MDX is generic and geared toward academia and many business questions result in very complex MDX code (where MDX is the query language of XMLA/ODBO). Concepts like traffic light reporting, currency translation, complex currency and unit handling or inactive parts of the definition are missing completely. These features have to be enhanced (if possible) by the calling application.
Other systems use JOlap, a Java based online analytical processing (OLAP) API that provides an OLAP model that is powerful and complex. Again, the API only treats the data retrival itself and it is difficult and time-consuming to translate the query views from an application's format to the API.
Other existing APIs do not provide concepts such as traffic light reporting (exception calculation) and list calculation, and therefore put this load on the calling applications, reducing the accuracy and effectiveness of the API in a business information system.
It would be desirable to provide improved methods and systems for executing query views and for otherwise allowing interaction between calling applications and called applications, including situations where the called applications are external applications or include external data, without putting the translation and enrichment efforts on the calling application.